Skip to main content

Full text of "The new industrial engineering : information technology and business process redesign"

See other formats


-^ O 




Thomas H. Davenport 
James E. Short 

CISR WP No. 213 

Sloan WP No. 3190-90 

Center for Information Systems Research 

Massachusetts Institute of Technology 

Sloan School of Management 

77 Massachusetts Avenue 

Cambridge, Massachusetts, 02139-4307 




Thomas H. Davenport 
James E. Short 

June 1990 

CISR WP No. 213 

Sloan WP No. 3190-90 

®1990 T.H. Davenport, J.E. Short 
Published in Sloan Management Review, Summer 1990, Vol. 31, No. 4. 

Center for Information Systems Research ^^** ^=^^RfF§ - DP^/i/gy 

Sloan School of Management ^T i /IPf ?i *''*'rr r .. 


Massachusetts Institute of Technology j w.i.l. L .'Bh.^RfES 

M 7 2000 


The New Industrial Engineering: 
Information Technology and Business Process Redesign 

Thomas H. Davenport James E. Shon 

Emsi and Young MIT Sloan School of Management 


At the turn of the century, Frederick Taylor revolutionized the design and improvement of 
work with his ideas on work organization, task decomposition and job measurement. Taylor's 
basic aim was to increase organizational productivity by applying to human labor the same 
engineering principles that had proven so successful in solving technical problems in the 
workplace. The same approaches that had transformed mechanical activity could also be used to 
structure jobs performed by people. Taylor, rising from worker to chief engineer at Midvale Iron 
Works, came to symbolize the ideas and practical realizations in industry that we now call 
industrial engineering (EE), or the scientific school of management^ In fact, though work design 
remains a contemporary IE concern, no subsequent concept or tool has rivaled the power of 
Taylor's mechanizing vision. 

As we enter the 1990's, however, two newer tools of the "information age" are beginning 
to transform organizations to the degree that Taylorism did earlier. These are information 
technology — the capabilities offered by computers, software applications, and 
telecommunications — and business process redesign — the analysis and design of work 
flows and processes within an organization. The ideas and capabilities offered by these two tools 
working together have the potential to create a new type of industnal engineering, changing the 
way the discipline is practiced and the skills necessary to practice it 

This article explores in detail the relationship between information technology (IT) and 
business process redesign (BPR). We repon on research conducted in nineteen companies, 
including detailed case studies from five firms engaged in substantial process redesign. After 
defining business processes in greater detail, we extract from the experiences of companies we 
studied a generic five-step approach to redesigning processes with IT. We then define the major 
types of processes, along with the pnmary role of IT in each type of process. Examples are 
provided throughout of specific effons within these firms to use IT to radically redesign and 
upgrade particularly important business processes — some as pan of a total business redesign, 
others as more isolated, but still valuable, effons. Finally, management issues encountered at our 
research sites in using IT to redesign business processes are considered. 


IT in Business Process Redesign 

The importance of both information technology and business process redesign is well 
known to industrial engineers, albeit as largely separate tools for use in specific, limited 
environments. 2 IT is used in industrial engineering as an analysis and modelling tool, and lE's 
have often taken the lead in applying IT to manufacturing environments. Well-known examples of 
IT use in manufacturing include process modelling, production scheduling and control, materials 
management information systems, and logistics. Indeed, in most cases where IT has been used 
proactively to redesign work in a given firm, this redesign has most likely been in the 
manufacturing function, and industrial engineers are the most likely individuals to have carried it 

EE's have begun to analyze work activities in nonmanufacturing environments, but their 
penetration into offices has been far less than in factories. Many office work "innovations", such 
as shared stenography and typing pools, have come and gone. IT has cenainly penetrated the 
office and services environments — in 1987 Business Week reported that almost 40% of U.S. 
capital spending went to information systems, some $97 billion a year — but IT has been used in 
most cases to hasten work rather than to transform it.^ In fact, the discipline of systems analysis, 
as practiced by IT professionals in designing computer and telecommunications applications to 
meet business needs, draws heavily from the work decomposition approaches of Taylorism and 
scientific management. With few exceptions, IT's role in the redesign of nonmanufacturing work 
has been disappointing; few firms have achieved major productivity gains."* Aggregate 
productivity figures for the U.S. have shown no increase since 1973.^ 

Given the growing dominance of service industries and administrative functions in the 
Western economies, this type of work is as much in need of analysis and redesign as the 
manufacturing environments to which IT has already been applied. To accomplish this, many 
firms have found that a broader view of both IT and business activity, and of the relationships 
between them, is now necessary. IT should be viewed as more than an automating or mechanizing 
force; it can fundamentally reshape the way business is done. In short, business should be viewed 
as more than a collection of individual or even functional tasks; instead it should be broken into 
processes that can be designed for maximum effectiveness, in both manufacturing and service 

Our research also suggests that IT can also have a stronger role in business process 
redesign than that of useful tool. In leading edge practice, IT and BPR have a recursive 
relationship, as Figure 1 illustrates. Each is the key to thinking about the other. Thinking about 
information technology should be in terms of how it supports new or redesigned business 
processes, rather than business functions or other organizational entities. And thinking about 
business processes and process improvements should be in terms of the capabilities information 

technology can provide. We refer to this broadened, recursive view of IT and BPR as the new 
industrial engineering. 

Figure 1 

The Recursive Relationship Between IT Capabilities 

and Business Process Redesign 

How can IT support business processes? 

Information Technolo 

Business Process Redesign 

How can business processes be transformed using IT? 

Why Now? 

Unlike Taylor's world at the turn of the century, businesses today face new competitive 
threats and uncenainiies on a global scale. Companies face mounting pressures to improve 
strategic and operational performance in product development, product delivery, and customer 
service and management. In these areas firms strive to reduce cost and time to market, while 
simultaneously improving quality, service and risk management.^ 

Where Taylor could focus on workplace rationalization and individual task efficiency in 
confronting a largely stable business environment, today's corporations do not have the luxury of 
such environmental stability.^ Individual tasks and jobs change faster than they can be redesigned. 
Responsibility for an outcome is spread over a group, rather than assigned to the single individual 
as in the past. Today, companies increasingly find it r.:cessary to develop more flexible, team- 
oriented, coordinarive and communication-based work capability. In short, rather than maximizing 
the performance of particular individuals or business junctions, companies must maximize within 
and across entire organizations a set of interdependent activities designed to produce value for a 
customer. Such business processes are a new approach to coordinating among organizational 
entities, and information technology's promise — and perhaps its ultimate impact — is to be the 
most powerful tool in the 20th century for reducing the costs of this coordination.^ 

What Are Business Processes? 

We define business processes as a set of logically-related tasks performed to achieve a 
defined business outcome. This is similar to Pall's definition of process as "the logical 
organization of people, materials, energy, equipment, and procedures into work activities designed 
to produce a specified end result (work product)." ^ 

A set of processes form a business system — the way in which a business unit, or a 
collection of units, carries out its business. Processes have rwo important characteristics: 

1. they have customers; that is, processes have defined business outcomes, and there are 
recipients of the outcomes. Customers may be either internal or external to the firm; and 

2. they cross organizational boundaries; that is, normally the occur across or between 
organizational subumts. Processes are generally independent of formal organizational 

Common examples of processes meeting these criteria include: 

Developing a new product 

Ordering goods from a supplier 

Creating a marketing plan 

Processing and paying an insurance claim 

Writing a proposal for a government contract 

The process of ordering goods from a supplier, for example, typically involves multiple 
organizations and functions. The eventual user of the goods, the purchasing department, and the 
supplier organization ail are panicipants. The user could be viewed as the customer of the process. 
The process outcome could be either the creation of the order, or perhaps more usefully, the actual 
receipt of the goods by the user. 

The examples of processes mentioned thus far have been large-scale, affecting whole 
organizauons or groups. It is also possible to cite examples of more detailed processes that meet 
the definitional criteria above. These might include the process of installing a windshield in an 
automobile factory, or completing a monthly departmental expense repon. IT-driven process 
redesign may also be desirable for these more detailed processes, though the implications of 
redesigning these detailed processes may be important only in the aggregate. In many of the firms 
we studied, analyzing processes in great detail was highly appropriate for some purposes, e.g., the 
detailed design of an information system or data model to support a specific work process. 
However, in the firms that were truly beginning to redesign the way their business functions, 
however, a broader view of processes was taken. 

A Brief History of Process Thinking 

Process thinking has become widespread over the past several years, due largely to the 
quality movement. Industrial engineers and others who wish to improve the quality of operations 
are urged to look at an entire process, rather than a particular task or business function. ^^ At IBM, 
for example, "process management will be the principal IBM quality focus in the coming years." ^ ^ 
But process discussions in the quality movement's literature rarely even mention information 
technology. Rather, the focus is usually on improving process control systems in a manufacturing 
context; when IT is discussed, it is in the context of factory floor automation. Recent IE literature 
also borders on process thinking when advocating cross-functional analysis, '^ although, as will be 
described below, cross-functional processes are only one possible type of process. 

Other than the quality-oriented manufacturing process redesign many companies have 
undertaken, most processes in major corporations have not been subject to rigorous analysis and 
redesign. Indeed, many of our current processes result from a series of ad hoc decisions made by 
functional units, with litde attention to efficiency and effectiveness across the entire process. Many 
processes have never even been measured. In one of the manufacturing companies we studied, for 
example, no one had ever analyzed the elapsed time from a customer's order to delivery. Each 
individual department involved in the product delivery process, such as sales, credit checking, and 
shippmg, felt that it had optimized its own performance, but in fact the overall process was quite 
lengthy and unwieldy. 

Even fewer business processes have been analyzed with the capabilities of IT in mind. 
Most business processes were developed before modem computers and communications even 
existed. When technology has been applied to processes, it is usually to automate and/or speed up 
isolated components of an existing process. This creates problems of communications within 
processes and impediments to process redesign and enhancement. For example, in a second 
manufacturing firm where we analyzed business processes, the procurement process involved a 
vendor database, a materials management planning system, and accounts payable and receivable 
systems, all separate and running on different hardware platforms with different data structures. 
Again, each organizational subunit within the process had developed and optimized its own IT 
application, but no one subunit had looked at (or had responsibility for) the process in its entirety. 
We believe the problems this firm experienced are very common in most businesses today. 

Redesigning Business Processes With IT: Five Steps 

Our message thus far is that, based on our research findings, many organizations need to 
redesign key business processes around the capabilities offered by IT. We observed, however, 
that companies often struggle to effectively implement BPR. In this section, we outline a generic. 

five step approach to redesigning processes with IT. We then define the major types of processes 

we encountered in our research, and describe the primary roles of IT in each type. 

Assuming that a company has decided its processes are inefficient or ineffective, and 

therefore in need of redesign, how should it then proceed? This is a straightforward activity, but 

five major steps are involved: develop the business vision and process objectives, identify the 

processes to be redesigned, understand and measure the existing process, identify IT levers, and 

then the actual design and prototyping of the new process (See Figure 2). We observed most or all 

of these steps being performed in companies that were succeeding with BPR. Each step is 

described in greater detail below. 

Figure 2 
Five Steps in Process Redesign 

Develop Business Vision and Process Objectives 
Prioritize objectives and set stretch targets 


Identify Processes to Be Redesigned 
identify critical or bottleneck processes 


Understand and Measure Existing Processes 
• Identify current problems and set baseline 


Identify IT Levers 
Brainstorm new process approaches 


Design and Prototype Process 
Implement organizational and technical aspects 

Develop Business Vision and Process Objectives 

When process redesign has been undertaken in the past, it was typically done with the 
objective of simply "rationalizing" the process, i.e., eliminating obvious bottlenecks and 
inefficiencies, without any particular business vision or context in mind. This was the approach of 

the "work simplification" aspect of industrial engineering, an important legacy of Taylorism. An 
example of the rationalization approach is given in the following quote out of a 1961 "Reference 
Note on Work Simplification" from Harvard Business School: 

A good manager asks himself why things are done as they are, extending his 
inquiry to every aspect of the job and the surroundings in which it is performed, 
from the flow of paper work to the daily functioning of his subordinates.. .He is 
expected to supply the stimulus and show that job improvement or simplification of 
work is not only important but also is based on common-sense questioning aimed at 
uncovering the easiest, most economical way of performing a job.^^ 

Our research suggests strongly that rationalization is not an end in itself, and is thus 
insufficient as a process redesign objective. Furthermore, rationalization of highly decomposed 
tasks may lead to a less efficient overall process. Instead of task rationalization, redesign of entire 
processes should be undertaken with a specific business vision and related process redesign 
objectives in mind. 

In most of the successful redesign examples we analyzed, the company's senior 
management had developed a broad strategic vision into which the process redesign activity fiL^'* 
At Xerox, for example, this vision involved taking the perspective of the customer, and developing 
systems rather than standalone products, both resulting in the need for cross-functional integration. 
At Westinghouse, the vision consisted largely of improving product quality. Ford's well known 
vision involved adopting the best practices of Japanese automobile manufacturers, including those 
of Mazda, of which it is a partial owner. 

Each of these visions resulted in specific objectives for process redesign. The most likely 
objectives for process redesign are the following: 

• Cost reduction - this objective was implicit in the "rationalization" approach. Cost is an 
important redesign objective in combination with others, but insufficient in itself 
Excessive attention to cost reduction results in tradeoffs that are usually unacceptable lo 
process stakeholders. While optimizing on other objectives seems to bring costs into line, 
optimizing on cost does not bring about other objectives. 

• Time reduction - Time reduction has been only a secondary objective of traditional 
industrial engineering. Increasing numbers of companies, however, are beginning to 
compete on the basis of time.'^ Processes, as we have defined them, are the ideal unit on 
which to focus time reduction analysis. One common approach to cutting time from a 
product design process is to make the steps in the process begin simultaneously, rather than 

sequentially, using IT to ccx)rdinate design directions among the various functional 
panicipants. This approach has been taken, for example, in the design of computers, 
telephone equipment, automobiles, and copiers (by Digital Equipment, AT&T Bell Labs, 
Ford, and Xerox, respectively). 

• Output quality - All processes have outputs, be they physical — such as in 
manufacturing a tangible product — or informational — such as in adding data to a 
customer file. Output quality has frequendy been the focus of process improvement in 
manufacturing environments; it is just as important an objective in service industries, and in 
processes with only internal customers. The specific measure of output quality may be 
uniformity, variability, or freedom from defects; this should be defined by the customer of 
the process. For example, Bruns and McFarlan^^ have described how Otis Elevator 
redesigned its elevator service dispatching process around an information system, radically 
improving service quality and consistency. 

• Quality of work life (QWL)/learning/empowerment - A frequently neglected 
objective of process redesign is the work life quality of the individuals carrying it out. IT 
can lead either to greater empowerment of individuals, or to greater control. Zuboff has 
pointed out that IT-intensive processes are often simply automated, and that the 
"informating" or learning potendal of IT in processes is often ignored. ^^ Moreover, Schein 
has pointed out that organizations often do not provide a supportive context for individuals 
to introduce or innovate with IT.^^ Of course, it is rarely possible to optimize ail objectives 
simultaneously, and in most firms, the strongest pressures are to produce tangible benefits. 
Yet many of the managers in firms we studied believed in the value of learning and 
empowerment objectives, and were struggling to determine how to advance thenx 

Some firms have been able to achieve multiple objectives in redesigning processes with IT. 
American Express, for example, set out to improve the cost, time, and quality of its process for 
making credit authorization decisions by embedding the knowledge of its best authorizers in an 
"Authorizer's Assistant" expert system. This successful redesign led to a $7 million annual 
reduction in costs due to credit losses, a 25% reduction in the average time for each authorization, 
and a 30% reduction in improper credit denials. Hewlett Packard, in applying IT to the redesign of 
several key manufacturing processes, also found that it could improve cost, time, and quality 

Finally, all firms found it important to be specific in setting objectives, even to the point of 
quantification. Though it is difficult to know how much improvement is possible in advance of a 

redesign, "reach should exceed grasp". Setting goals that will stretch the organization will also 
provide inspiration and stimulate creative thinking. For example, a company might decide to 
reduce the time to bring new products to market by 80%, or reduce output errors from 12 per 
thousand to 1 per thousand. In the accounts payable process at Ford, the "stretch" goal was to 
eliminate invoices — to pay suppliers upon receipt of their products or services. This goal has 
since been achieved with the aid of an information system to confirm expected deliveries at the 
loading dock, and as a result. Ford has eliminated three quarters of the jobs in its accounts payable 

Identifying Processes to Be Redesigned 

Our research suggests that most organizations could benefit from IT-driven redesign of all 
their business processes. However, the amount of effort involved in process redesign, and in 
building IT solutions to support redesigned processes, places a practical limitation on total 
corporate redesign. Even when total redesign was the ultimate objective, the company selected a 
few specific processes for its initial redesign efforts. Moreover, when there was insufficient 
commitment to total redesign, a few successful examples of IT-enhanced processes were viewed as 
a powerful selling tool. 

The means by which processes to be redesigned are identified and prioritized is one of the 
key issues in process redesign. This is often difficult because most managers do not think about 
their business operations in terms of processes. There are two major approaches to the issue. The 
first, which we label the "exhaustive" approach, attempts to rigorously identify all processes within 
an organization and then prioritize them in order of redesign urgency. The second, which we refer 
to as "high-impact", attempts to identify only the most important processes or those most in 
conflict with the business vision and process objectives, using a minimum of time and effon. 

The exhaustive approach to process identification is often associated with the "information 
engineering" method of information system planning (developed by James Martin in the early 
1980's), in which an organization's use of data dictates both processes to be redesigned, and the 
design ouUine for specific processes. Most information engineering projects, however, are not 
process-oriented. '^ 

One specific information engineering method, employed at several divisions of Xerox in 
Europe and the U.S., involves identifying business activities and the data entities used by them in a 
large business activity by data entity matrix. The clusters of activity-entity interactions in the cells 
of the matrix are the major business processes of the organization. Xerox managers must then 
prioritize processes in the order for which new IT applications suppon would be provided. 
Although the process identification activity in some Xerox divisions took as little as three months, 
many organizations have found the information engineering approach to be very time consuming. 

The alternative to the exhaustive approach is to focus quickly on high-impact processes. 
Most organizations have some idea of which business areas or processes are most crucial to their 
success, or those which are most "broken" or inconsistent with the business vision. If not, these 
processes could normally be identified in a few senior management workshops (a discussion of 
process types, such as that presented below, would be a useful topic in such a workshop), or 
through extensive interviewing. At IBM, the sales force was surveyed to determine the relative 
importance of multiple customer suppon processes; the generation of special bids was perceived as 
being of highest priority, and was the fu^st process to be redesigned. Some of the business areas 
or problems identified as important may need to be further refined into processes. 

Companies we studied that employed the high-impact approach generally found it 
sufficient Those companies taking the exhaustive approach have not had the resources to quickly 
address all identified processes; why identify them if they cannot be addressed? As a rough "rule 
of thumb", most companies in our research were unable to redesign and support with IT more than 
ten to fifteen major processes per year (i.e., one to three per major business unit); there is simply 
not enough management attention to do more. Funhermore, some organizations have abandoned 
the exhaustive approach, as resources or time consumed became excessive.^ 

Whether the exhaustive or high-impact approach is used, companies have found it useful to 
classify each process to be redesigned in terms of beginning and end points, interfaces, and 
organization units (functions or departments) involved, including in particular the customer uniL A 
thorough view of a process will usually result in a broader scope than managers within the 
organization have previously taken. For example, a sales manager may be aware that there are 
inefficiencies in the customer order entry area. A skilled process consultant might decide that the 
whole process of negotiating, receiving, and fulfilling orders needs to be redesigned. Whether this 
broader view of the problem is broken down into three processes, or viewed as one, is not 
important; expanding the scope of the process analysis is the key issue. 

High-impact processes should also have owners. In virtually all the cases of process 
redesign we analyzed, an important step was getting owners to buy-in to the idea of process 
redesign, and the scope of process analysis, at an early stage. In several companies, it was felt that 
the owner's job should be either above the level of the functions and units the process crosses, or, 
if on the same level, the owner should be willing to change the status quo. The difficulty with this, 
however, is that some processes only come together at the CEO level; in this situation, the CEO 
should designate a senior manager as owner and invest him or her with full change authority. 
Processes that are fully contained within a single function or depanment can normally be owned by 
the functional or departmental manager under which they are earned out. 


Understanding and Measuring Existing Processes 

Companies had two primary reasons for understanding and measuring existing processes 
before redesigning them. First, problems with existing processes needed to be understood so that 
they would not be repeated. Secondly, it was important to measure existing processes to set a 
baseline for future improvements. If the redesign objective was to cut time and expense out of a 
process, the time and cost consumed by the "untouched" process had to be accurately measured. 
Wesnnghouse Productivity and Quality Center consultants found that simply graphing the 
incremental cost and time consumed by the tasks of a process can often suggest initial areas for 
redesign. These graphs look like "step functions" showing the incremental contribution of each 
major task. 

Understanding and measuring existing processes can easily be overemphasized, however. 
In several firms, the "stretch" goal in redesigning a process was less eliminating problems or 
bottienecks, than in making radical improvements over the status quo. Designers should be 
working with a clean slate, though informed by past process problems and errors. Similarly, the 
process should not be measured for measurement's sake. Only the specific objectives that are the 
focus for redesign should be measured. As with the high-impact process identification approach, 
an "80-20" philosophy is usually appropriate. 

Identifying IT Levers 

In even the most sophisticated industrial engineering approach, IT capabilities were thought 
of only after a process had been designed. The conventional wisdom in IT usage has always been 
to fu-st determine the business requirements of a function, process, or other business entity, and 
then develop a system. The problem with this approach is that an awareness of the capabilities IT 
brings to a process can — and should — influence its design. Knowing that product development 
teams can exchange computer aided designs over large distances, for example, might affect the 
structuring of a product development process. Consideration of the role of IT in a process must 
therefore be done in the early stages of its redesign. 

In several firms, this was accomplished in brainstorming sessions, with the process 
redesign objectives and existing process measures in hand. It was also useful to have in hand a list 
of the generic capabilities of IT in improving business processes. In the broadest sense, all of ITs 
capabilities involve improving coordination and information access across organizational units, 
thereby allowing for more effective management of task interdependence. More specifically, 
however. Figure 3 illustrates eight critical IT capabilities and their organizational impacts. 


Figure 3 
IT Capabilities and Their Organizational Impacts 


Organizational Impact/Benefit 


IT can transform unstnictured processes into routinized transactions 


IT can transfer informauon with rapidity and ease across large distances, 
making processes independent of geography 


IT can replace or reduce human labor in a process 


IT can bring to bear complex analytical methods on a process 


IT can Dnng vast amounts of detailed informanon into a process 


IT can enable changes in the sequence of tasks in a process, often 
allowing multiple tasks to be worked on simultaneously 


IT allows the capture and disseminadon of knowledge 
and expertise to improve the process 


IT allows the detailed tracking of task status, uiputs, and outputs 


IT can be used to directly connect two parties within a 
process that would otherwise communicate through an 
intermediarv (internal or external) 

There are undoubtedly other important IT capabilities that can reshape processes. 
Organizations may want to develop their own lists of capabilities that are specific to the types of 
processes they employ. The point is twofold; IT is so powerful a tool that it deserves its own step 
in process redesign, and IT can actually create process design options rather than simply 
supporting them. 

Process Design and Prototyping 

For most firms, the final step in this approach is to factor in all the above steps and design 
the process. This is usually done by the same team that performed the previous steps, getting input 
from process consdtuencies and using brainstorming workshops as the mode of operations. A key 
point is that the actual design is not the end of process redesign activities. Rather, the new design 
can be viewed as a prototype, with iteration expected and managed through successively bener 
designs. Key factors and tactics to consider in process design and prototyping include the use of 
IT as a design tool, generic design criteria, and the use of organizational prototyping for 
implementing redesigned processes. 


Designing a business process is largely a matter of diligence and creativity. Emerging IT 
technologies, however, are beginning to facilitate the "process" of process design. Some 
computer-aided systems engineering (CASE) products are primarily designed to draw process 
models. The ability to rapidly draw models and make changes as suggested by process owners 
will speed redesign and facilitate owner buy-in. Some CASE products can actually generate 
computer code for the information systems application that will suppon a modelled business 

Several Xerox divisions, for example, are moving directiy from process modelling to code 
generation for high-priority processes. They repon improved productivity and high user 
satisfaction with the resulting systems. A further benefit is that when the business process 
changes, the IS organization can rapidly modify the affected system. In Xerox's case, the tool 
employed for this purpose was Texas Instruments' Information Engineering Facility, one of 
several major CASE products. Use of this product, and generally of any code generation product, 
presumes that process designers will use the "exhaustive" approach to process identification, as 
described above. 

We observed several different design criteria that were used by companies in evaluating 
alternative designs. Most important, of course, is the likelihood that a design will satisfy the 
chosen design objectives. Others mentioned in interviews included the simplicity of the design, the 
lack of buffers or intermediaries, the degree of control by a single individual or department (the 
more concentrated the process control, the better), the balance of process resources, and the 
generalization of process tasks (so that they can be performed by multiple individuals). 

Mutual Benefit Life's (MBL) redesign of its individual life insurance underwriting process 
illustrates a final, imponant point about process design. In the past, underwriting a life insurance 
policy was an assembly line process. At MBL, it involved 40 steps with over 100 people in 12 
functional areas and 80 separate jobs. To streamline this lengthy and complex process, MBL 
undertook a pilot project with the goal of improving productivity by 40%. To integrate across the 
12 functional areas, multiple jobs, and multiple employees involved, MBL created a new role, 
called Case Manager. This role was designed to centrally perform and coordinate all underwriting 
tasks, utilizing a workstation-based computer system capable of pulling data from all over the 
company. Upon experimenting with the new role and underwriting process, the firm learned that 
two additional roles were necessary on some underwriting cases: specialists, such as lawyers or 
medical directors, in knowledge-intensive fields, and clerical assistance, drawn from "pools" of 
typists, data entry personnel, and so fonh. With the new role and redesigned process, senior 
managers at MBL are confident of reaching the 40% goal in a few months. 

Mutual Benefit's new underv-xiting process, as well as IT support for it, was prototyped 
and subsequently modified. This example illustrates the value of creating organizational 


prototypes, as well as IT application prototypes, in IT-driven process redesign. The concept of 
prototyping IT applications is rapidly gaining acceptance in the application development field. 
Advocates argue that prototyping an IT change is usually faster than conventional "life cycle" 
development in getting to the end result, and, more importantly, the end result is much more likely 
to satisfy the customer. There is considerable interest in extending prototyping to business process 
changes and organizational initiatives. ^^ The implications of this extension are that process 
designs, after agreement by owners and stakeholders, would be implemented on a pilot basis 
(perhaps in parallel with existing processes), examined regularly for problems and objective 
achievement, and modified as necessary. As the process approached final acceptance, it would be 
phased into full implementation. 

Defining Process Types 

The five steps descnbed above are sufficiently general to apply to most types of 
organizations and processes. Yet the specifics of redesign activities vary considerably by the type 
of process under examination. Different types of processes require different levels of management 
attention and ownership, need different forms of IT support, and have different business 
consequences when redesigned. In this section we present three different dimensions in which 
processes vary, and the resulting process types are described with examples. 

Understanding and classifying the different types of processes is imponant because 
organizations can appear to managers as a seamless web of interconnected processes, no one 
entirely separate nor even definable without the others. Also, as we note above, few managers are 
familiar with process thinking; knowing about multiple process types helps managers to relate 
these processes to their own experience. With multiple process types in mind, a manager can 
begin to isolate particular processes for analysis and redesign, including activities which, without 
process thinking, might otherwise be overlooked. 

There are three major dimensions that can be used to define processes (see Figure 4). 
These are the organizational entities or subunits involved in the process, the type of objects 
manipulated in the process, and the type of activities taking place in the process. Each dimension 
and resulting process type is described below, along with a discussion and examples of the role of 


Figure 4 
Types of Processes 

Process Dimension 
and Type 

Typical Example 

Typical IT Role 



Order from a supplier 

Lower transaction costs; 
eliminate intermediaries 


Develop a new product 

Work across geography; 
greater simultaneity 


Approve a bank loan 

Role and task integration 


Manufacture a product 

Increased outcome flexi- 
bility; process control 


Create a proposal 

Routinizing complex 


Fill a customer order 

Reduce time and costs; 
increase output quality 


Develop a budget 

Improve analysis; 
increase participation 

Defining Process Entities 

Because processes take place between organizational entities, it is possible to classify them 
by the type of entities involved. Each type has different implications for IT benefits. 

Interorganizational processes are those taking place between two or more different 
business organizations. Others have pointed out the increased emphasis on both intercompany 
relationships in the form of strategic alliances or value-adding pannerships^^ and the use of IT 
between organizations. 23 Johnson and Lawrence, for example, cite McKesson's Economost 
system for pharmacy distribution as the vehicle for establishing, and enhancing, the value-adding 
partnership between McKesson and its pharmacy customers. However, focusing on 
interorganizational processes and the role of IT in facilitating these processes (without necessarily 
changing the equity strucnire between firms) is a new emphasis. 


Much of this work implicitly suggests that it is no longer possible to improve significantly 
internal business performance without redesigning interorganizational processes. This goes 
beyond our classical concern with controlling the environment. Increasingly, companies are 
concerned with coordinating acuvines that extend into the next (or previous) company along the 
value added chain (e.g., how your distributor sells your product to the end customer, or how your 
supplier numbers the components it sells to you). Several U.S. retail, apparel, and textile 
companies, (for example, Dillard's Depanment Stores, Haggar Apparel, and Burlington 
Industries) have linked their business processes to speed reordering of popular apparel fashions. 
When Dillard's inventory of a particular pants style falls below a specified level, Haggar is notified 
electronically. If Haggar does not have the cloth to manufacture the pants, Burlington Industries is 
notified electronically. As this example, called Quick Response, and other early adopters of 
electronic data interchange (EDI) illustrate, information technology is the major vehicle by which 
this interorganizational linkage is executed and enhanced. 

For most companies, simple market relationships are the most common source of 
interorganizational processes. All the tasks involved in a selling/buying transaction form a critical 
process for sellers, and an increasingly imponant one for buyers seeking greater procurement 
quality, cost efficiency, and responsiveness. Yet much of the focus in improving market 
relationships through IT has been on a simple transaction level, rather than on an 
interorganizational business process level. Again, this is well illustrated by much of the EDI 

Buyers and sellers involved in most EDI have concentrated on speeding up routine 
purchasing transactions, such as invoices or bills of materials. Few companies implementing EDI 
have attempted to redesign the broader procurement process surrounding transaction automation — 
from the awareness that a product is needed, to the development of approved vendor lists, or even 
to the delivery and use of the purchased product. In the future, sellers will need to look at all 
buyer processes in which their products are involved. 

Moreover, many firms will need to help the buyer improve those processes. DuPont's 
concept of "effectiveness in use" as the major criterion of customer satisfaction with a product is 
one example of a leading approach to measuring the effectiveness of interorganizational processes. 
DuPont is thus motivated not simply to sell a product, but to link its internal processes for creating 
and providing value to the product to its customers' processes for using the product. This concept 
led DuPont to be an early user of EDI-provided Material Safety Data Sheets, furnished along with 
the chemicals it sells to its customers to ensiu^ their safe use. 

At Westinghouse, an interorganizational process approach was used in dealing with 
Portiand General Electnc (PGE), a major customer of power generation equipment. Managers at 
PGE called upon Westinghouse's Productivity and Quality Center, a national leader in process 


improvement, to help them implement EDI. The Center did have experience in EDI, but the team 
assigned to work with PGE asked if they could analyze the entire process by which it procured 
equipment from Wesringhouse and other suppliers. The Westinghouse team found that while 
implementing EDI could yield efficiencies on the order of 10%, making major changes in the 
overall procurement process, including using EDI and bypassing the purchasing department 
altogether for most routine purchase orders, could lead to much greater savings. In one case, the 
time to execute a standard purchase order, for example, could be reduced from 15 days to half a 
day; the cost could be reduced from almost $90 to $10. 

A second major type of business process is interfunctionai. These processes are within 
(internal to) the organization, but cross several different functional or divisional units. 
Interfunctionai processes should be viewed as task sets that achieve major operational objectives, 
such as new product realization, asset management, or production scheduling. They may also 
include important management processes, such as strategic planning, personnel development, or 
financial control. Customer service, product development, and product delivery are examples of 
major interfunctionai processes. Most management processes, e.g., planning, budgeting, and 
human resource management, are also typically interfunctionai. 

In manufacturing, many companies found in their quality improvement programs that 
producing quality products and services required addressing difficult interfunctionai issues. Yet 
most firms have never even listed their key interfunctionai processes, let alone analyzed or 
redesigned them, with or without the aid of IT. 

Two companies which recently have analyzed their key interfunctionai business processes 
are Baxter Healthcare Corporation and US Sprint Communications Company. At Baxter, the 
firm's 1985 merger with American Hospital Supply provided the context for a major reanalysis of 
key business strategies, and the alignment of the IT infrastructure to those strategies. 2** As part of 
a seven month IT planning effort, the company defined 29 major interfunctionai processes, and 
analyzed the current and future role of IT in supporting them. For example, in the distribution 
area, the company identified order entry, inventory, warehouse management, purchasing, 
transportation, and equipment tracking as key processes. The success of this IT planning effort led 
Baxter to incorporate the process definition approach into its annual corporate planning process. 

At US Sprint, well-publicized problems with its customer billing system prompted the 
company's IT function to develop a strategic data model for the entire business as part of a 
comprehensive systems improvement program. This model defined the corporate data entities and 
key interfunctionai processes necessary to run die business. Sprint is now involved in a major 
new phase of the program, assigning ownership to key processes, and continuing to identify 
improvements — and ways to measure them — in each process. The data model definition and 


other activities in the systems improvement program raised the IT organization's composite internal 
quality index by more than 50% in one year.^ 

A major problem in redesigning interfunctional processes is that most information systems 
of the past were built to automate specific functional areas or parts of functions. Few third-party 
application software packages have been developed with support of a full business process in 
mind. However, organizations increasingly are realizing the need for interfunctional systems. Yet 
very few have modelled existing interfunctional processes or redesigned them, and companies will 
run into substantial problems in building interfunctional systems without such models. 

Interindividual processes are those involving tasks within and across small work 
groups, typically within a function or department. Examples of such processes might include a 
commercial loan group approving a loan in a bank, or a flight crew preparing a flight for takeoff at 
an airline. This type of process has become more important as companies shift to self-managing 
teams as the lowest unit of organization. Information technology is increasingly capable of 
supporting interindividual processes; hardware and communications companies have developed 
new networking-oriented products, and software companies have begun to flesh out the concept of 
"groupware" (e.g., local area network-based mail, conferencing, and brainstorming tools).^^ 

Several companies, including GM's Electronic Data Systems (EDS) and several other IT 
vendors, are actively exploring IT tools and group dynamics methodologies to facilitate the 
effectiveness of meetings and small group interactions. At EDS, the primary focus is on enhancing 
automobile product development (clearly an interfunctional process) through the IT-facilitated 
development teams. The company's Center for Machine Intelligence has developed a computer- 
supported meeting room, and is studying its implications for group decision making and 
cooperative work.^"^ 

Interindividual processes may be the most efficient type, because all tasks within the 
process (and perhaps even the customer of the process) are within a small group. As companies 
begin to acknowledge both the value of process thinking and the role of self-managing teams, 
interindividual processes will become more common. It should be pointed out, however, that IT 
can make possible the execution of processes within teams of employees who may be scattered 
around a country' and even the world. As an example. Ford is renowned for its ability to create 
new car designs through teams whose members are both in Europe and in the U.S. Because Ford 
has standardized on computer-aided design systems, and created common data structures for the 
design process, engineers can share complex three-dimensional designs across the Atlantic. 
Similarly, a small team at Digital Equipment used the company's extensive electronic mail and 
conferencing capabilities to build the core of a new systems integration business. The team was 
scattered around numerous Digital facilities in the U.S. and Europe, and only rarely met in person. 

Defining Process Objects 

Pnxesses can also be categorized by the types of objects manipulated by the process. The 
two primary object types are physical and informational. In physical object processes, real, 
tangible things are either created or manipulated; manufacturing is the obvious example. 
Informational object processes create or manipulate information. Processes for making a decision, 
preparing a marketing plan, or developing a new product design are examples of informational 
object processes. 

Many processes involve the combination of both physical and informational objects. 
Indeed, adding information to a physical object as it moves through a process is a common way of 
adding value. Most logistical activities, for example, combine the movement of physical objects 
with the manipulation of information about their whereabouts. Success in the logistics industry is 
often dependent on the close integration of physical and informational outcomes in business 
processes; both UPS and Federal Express, for example, track package movement closely with 
computers and communications networks. 

The potential for using IT to improve physical processes is well known. It allows greater 
flexibility and variety of outcomes, more precise control of the process itself, reductions in 
throughput time, and elimination of human labor. These benefits have been pursued for the past 
three decades in the form of computer integrated manufacturing, robotics, and other forms of 
factory-floor automation. Still, manufacturing process flows are often the result of historical 
circumstance, and should usually be redesigned before further automation is applied. This is 
particularly true in low volume, "job shop" manufacturing environments. ^^ Redesigners of 
physical processes should also consider the role of IT in providing information to improve 
processes; Shoshana Zuboff has described this "informating" effect in detail for the paper 
industry. ^^ 

Strangely, the proponion of informational processes already transformed by IT is probably 
lower than that of physical processes. True, legions of clerks have become unemployed because 
of computers. But the majority of information processes to which IT has been applied are those 
involving high transaction volumes and low transaction complexity. Now that these have been 
conquered, the emphasis needs to shift to processes incorporating unstructured tasks and 
performed by high-skill knowledge workers. Relevant IT capabiUties for these types of processes 
include the storage and retrieval of unstructured and multi-media information, the capturing and 
routinizing of decision logic, and the application of far-flung and complex data resources to a 
problem. A computer vendor's advenising videotape, for example, illustrates how artificial 
intelligence and "hypenext"', or mixed-media databases, combine to lead a manager through the 
process of developing a budget for his depanment. The IT capabilities in the video are available 
today, but they are rarely applied to such information-intensive yet unstructured processes. 


Defining Process Activities 

The examples given thus far of typical business processes have involved two types of 
activities: operational and managerial. Operational processes are those involved in the day-to-day 
carrying out of the organization's basic business purpose, e.g., product development and 
production processes, and customer service processes. Managerial processes are those which help 
to control, plan, or provide resources for operational processes. Past uses of IT to improve 
processes, limited as they are, have been largely operational. We therefore will focus almost 
entirely on managerial processes in this section.^ 

It is not a new idea to apply IT to management tasks. For over twenty years, the potential 
of decision support systems, executive support systems, and other managerial productivity and 
information tools have been trumpeted. We believe, however, that the benefits have remained 
more potential than actual because of the absence of systematic process thinking. Few companies 
have rigorously analyzed managerial activities as processes subject to redesign. Even the notion of 
managerial activities involving defined outcomes (a central aspect of our definition of business 
processes) is somewhat foreign. How would such managerial processes as deciding on an 
acquisition or developing the agenda for the quarterly board meeting be improved if they were 
treated as processes — i.e., measured, brainstormed, and injected with IT capabilities? 

The generic capabilities of IT for reshaping management processes include improving 
analytic accuracy, enabling broader management participation across wider geographical 
boundaries, generating feedback on actions taken (the managerial version of "informating" a 
process), and streamlining the time and resources a specific process consumes. Texas Instruments 
and Xerox's corporate headquaners provide excellent examples. 

Texas Instruments has developed an expen system to facilitate the capital budgeting 
process. Managers in a fast-growing and capital-intensive TI division were concerned that the time 
and experience necessary to prepare capital budget request packages would become an obstacle to 
the division's growth. The packages were very complex, and few employees had the requisite 
knowledge to complete them accurately. The system was developed by two industrial engineers 
with expertise in both the technology and process. 

For TI, the system has radically improved the capital budget request process. Capital 
request packages prepared with the system require far less time than the manual approach, and 
conform better to the company's guidelines. One employee experienced in capital requests 
reponed a reduction in package preparation time from 9 hours to 40 minutes; of the first 50 
packages prepared with the system, only three did not conform to guidelines, compared to an 
average often using a manual approach. ^^ 

While many firms have developed executive information systems (EIS) for their senior 
managers, at Xerox Corporation headquaners, IT has been used to improve a specific managerial 


process, i.e., the review of division strategic plans. Prior to the development of the EIS, the 
planning process was somewhat haphazard; each division prepared its planning documents in a 
different format, and furnished different types of informadon to headquaners. Plans often came in 
too late for the corporate management committee to review them before the review meeting. An 
EIS was developed that included standard formats, specified information, and graphic templates 
for fast comprehension. Divisional plans were then created on executive workstations and 
delivered instantaneously over Xerox's network to all corporate management committee members. 
They can now read the plans beforehand and can move directly to decisions at the review meeting. 
The workstations are even used in the meeting itself, allowing revisions to be made and agreed 
upon before adjournment. As one manager put it, "...(the system) lets us communicate at higher 
speed and in greater depth. "^^ 

Management Issues in IT-Enabied Redesign 

Following the identification and redesign of the firm's processes (using either the 
exhaustive or high impact approach), the firms we studied found that several key issues remained 
to be addressed, and would be of ongoing imponance as they implemented process-oriented 
management. These issues included management roles in the redesign activity, organization 
structure implications, new skill requirements, creating a function to perform IT-enabled BPR, the 
proper direction for the IT infrastructure, and the need for continuous process improvement. We 
discuss each issue below. 

Management Roles 

Perhaps the greatest difficulty encountered by firms in bringing about IT-driven redesign is 
obtaining and keeping management commitment to the changes any redesign will bring. Because 
processes themselves cut across various parts of the organization, a process redesign effort driven 
by a single business function or unit will probably encounter resistance from other affected parts of 
the organization. Both high-level and broad support for change is necessary. 

To perform the five redesign steps described above, several companies created a cross- 
functional task force headed by a senior executive. These task forces included representation from 
key staff and line groups likely to be affected by the changes, including the IT and Human 
Resources functions. It was panicularly imponant that the customer of the process be represented 
on the team, even when the customer is external. The team composition was ideal when some 
members of the group had some record of process or operations innovation involving IT. 

As the redesign teams selected processes for redesign and developed redesign objectives, 
they needed to work closely with the managers and staff of the affected units. Of course, getting 
process changes implemented is usually more difficult than determining what changes should be 


made. Ideally, managing process change is similar to other types of change management, except 
that the cross-functional nattire of process redesign increases the number of stakeholders, thereby 
increasing the complexity of the effort 

It was also important to have strong senior management commitment to the redesign effort, 
up to and including the CEO. It was necessary to make clear throughout the organization that 
redesign was necessary, that differences of opinion would be resolved in favor of the customer of 
a process, and that IT would play an important role. In many cases, the CEO also communicated 
any structural implications of the redesign effon to affected organizational units and staff (the 
implications of process redesign for structure are discussed in the next section). 

An example of the importance of the CEO's role in process redesign is found at GUS 
Home Shopping, the largest home shopping company in Europe. GUS undenook a $90 million 
project to redesign its logistical processes with IT. The company's redesign objectives involved 
both cost and rime: to be able to sell a product within 5 minutes of its arrival on the loading dock, 
and to be able to deliver a product to the customer's door at an average cost of 60 cents. In 
meeting these objectives, the company's Managing Director commented on his role: 

To change our business to the degree we have demands integration. How involved 
should the Managing Director get in designing computer systems? My view is 
totally, because he's the one who can integrate across the entire organization. ^^ 

Process Redesign and Organizational Structure 

A second key issue is the relationship between process orientation and organizational 
structure. Certainly someone must be put in charge of implementing a process change, and then 
managing the redesigned process thereafter. But process responsibilities are likely to cut across 
existing functional and unit organizational structures. How can process organization and 
traditional functional organization be reconciled? 

One possible solution is to create a new organizational structure along process lines, in 
effect abandoning altogether other structural dimensions, such as function, product, or geography. 
There are risks to this, however: as business needs change over time, new processes will be 
created that cut across the previous process-based organization. This does not mean that a process- 
based structure cannot be useful, but only that a specific process-based structure will have to be 
changed frequently to closely follow how business is done. 

While no firm studied has converted wholly to a process-based structure, a few 
organizations have moved in this direction. For example, Apple Computer is beginning to 
incorporate a process orientation into its structure. Its CEO, John ScuUey, describes the company 
as one of the few major corporations built after the Information Age began. Apple has recentiy 
moved away from a functional structure to what executives describe as an IT-oriented, process- 


based, customer satisfaction-driven structure called "New Enterprise". The company relishes its 
lack of formal hierarchy; Apple managers describe their roles as highly diffuse, and team and 
project- based. 

A more conservative approach would be to create a matrix of functional and process 
responsibilities. However, because of the cross-functional nature of most processes, the 
functional manager who should have responsibility for a given process is not always easily 
identified. The company may also wish to avoid traditional functional thinking in assigning 
process responsibilities. For example, it may be wiser to give responsibility for the process of 
supplies acquisition to a manager who uses those supplies (i.e., the customer of the process), 
rather than to the head of the purchasing function. 

New Skill Requirements 

For process management to succeed over the long run, managers will need to develop 
facilitation and influence skills. Again, when processes cut across organizational units, traditional 
sources of authority may be of littie use in process change and improvement Managers will often 
find themselves trying to change the behavior of employees who do not work for them. In these 
cases, they must learn to persuade rather than to instruct, to convince rather than to dictate. Of 
course, these recommendations for change in managerial behavior are consistent with many other 
organizational maxims of the past several years; they just happen to be useful in process 
management as well.^ 

Several organizations that are moving toward IT-driven process management are 
conducting formal programs for the development of facilitation skills. These programs encourage 
less reliance on hierarchy, more cross-functional communication and cooperation, and more 
decisionmaking by middle- and lower-level managers. Such a program at American Airlines, 
called "Committing to Leadership", is being used to build an organizational infrastructure at the 
same time a new IT infrastructure is being built. At Levi Strauss, which has heavily used IT to 
facilitate inter-organizational processes (including the "Quick Response" processes described 
above, the company is encouraging individual decisionmaking to enable horizontal communication 
and business processes. 

An Ongoing Organization for Creating Process Change 

Organizations that have redesigned key processes will also need to establish an ongoing 
organization to oversee continuing redesign and organizational "tuning", and to ensure that 
information systems support process flows. In most companies, the analytical skills needed for 
redesigning processes are most likely to be found in the IT function. However, individuals in the 
IT function will also require a high degree of interpersonal skills to be successful as the "new 


industrial engineers". The ideal group would combine the responsibilities of multiple functional 
areas, e.g., information systems, industrial engineering, quality, process control, finance, and 
human resources. 

TTiere are a few emerging examples of such process change groups. Silicon Graphics has 
created a specific process consulting group for ongoing process management; it is headed by a 
director-level manager. On a project basis. Ford Motor increasingly combines IT function 
employees with industrial engineers to redesign key processes, as it did recently on a redesign of 
the pans warehousing process. 

At United Parcel Service, the Industrial Engineering function, which includes more than 
1500 EE's, is the traditional locus for process redesign. The UPS group is incorporating IT skills 
in the IE function at a rapid rate, and creating task forces with IT and IE representation for process 
redesign projects. Federal Express, its competitor, has gone even further, renaming its IE 
organization the "Strategic Integrated Systems Group", placing it within the Information Systems 
function, and giving it responsibility for designing and implementing major IT-driven business 

Process Redesign and the IT Organization 

Just as IT is a powerful force in redesigning business processes, process thinking has 
imponant implications for the IT organization and the technology infrastructure it builds. Though 
few IT groups will have the power and influence to lead an IT-driven redesign, there are several 
imponant roles they can play. First of all, the IT group may need to play a behind-the-scenes 
advocacy role, convincing senior management of the power offered by IT and process redesign. 
Secondly, as demand builds for process redesign expenise, the IT group can begin to incorporate 
the IE-oriented skills of process measurement, analysis, and redesign, perhaps merging with the IE 
function if there is one in the company. It can also develop an approach or methodology for IT- 
enabled redesign, perhaps using the five steps described above as a starting poinL 

What must the information systems function do technologically to prepare for process 
redesign? IT professionals must recognize that they will have to build most systems needed to 
suppon (or enable) processes rather than buying them from software package vendors, because 
most application packages are designed with particular functions in mind. IT professionals will 
need to build robust technology platforms on which process-specific applications can be quickly 
constructed. This implies a standardized architecture with extensive communications capability 
between computing nodes, and the development of shared databases. However, like the 
organizational strategies for process management described above, these are appropriate 
technology strategies for most companies, whether or not they are redesigning processes with IT. 


Continuous Process Improvement 

It is also important that process improvement be continuous. The concept of process 
improvement, as developed in the quality movement, requires first that the existing process be 
stabilized. The performance of the process then becomes predictable, and its capabilities become 
accessible to analysis and improvement.^^ Continuous process improvement occurs when the 
cycle of stabilizing, assessing, and improving a given process becomes an institutional practice. 
The concept of continuous process improvement has received considerable attention in 
manufacturing, due largely to the impact of Toyota Motor Company's production and just-in-time 
inventory {Kanban) systems. A key element in Kanban is continuous improvement, or "kaizen" (a 
Japanese term meaning continuous improvement). 

As in the Toyota example, IT-enabled business process redesign must generally be 
dynamic, constantly stressing process improvement through the application of IT. Those 
responsible for a process should constantly investigate whether new information technologies 
make possible new ways of carrying out a process. IT is continuing to evolve, and some 
forthcoming technologies will have substantial impact on the operational and management 
processes of the next decade. ^^ The IT infrastructure, as discussed above, must be robust enough 
to enable continued increases in functionality for the applications that support a particular process. 

Case Study: IT-Driven Process Redesign at Rank Xerox U.K. 

Rank Xerox U.K. (RXUK), a national operating company of Xerox Corporation, has 
engaged in the most comprehensive IT-driven process redesign of any company we have studied. 
The changes at RXUK have been led by David O'Brien, the division's Managing Director, who 
arrived at the company in 1985. O'Brien quickly came to two realizations about RXUK's 
business: first, the company needed to focus on marketing "office systems" rather than its 
traditional reprographics products; and secondly, the company's strong functional culture and 
inefficient business processes would greatly inhibit its growth. He began to see his own 
organization as a test bed for using integrated office systems to support integrated. business 
processes; if such a concept were successful, he could use RXUK as a model for customers. 

The company began to redesign its business in 1987. In a series of offsite meetings, the 
RXUK senior management team reappraised its external environment and mission, and then 
identified the key business processes needed for the company to succeed in its mission. The group 
began to restructure the organization around cross-functional processes, identifying high-level 
objectives for each process and creating task forces to define information and other resource 
requirements for each process. They created career systems revolving around facilitation skills and 
cross-functional management, rather than hierarchical authority. O'Brien decided to keep a 
somewhat functional formal structure, because functional skills would still be needed in a process 


organization, and because the level of organizational change might have been too great with a 
wholly new structure. 

The level of change was still very high. Several senior managers depaned because they 
could or would not manage in the new environment. Two new cross-functional senior positions, 
called "facilitating directors", were created, one for organizational and business development, the 
other for process management, information systems, and quality. O'Brien took great advantage of 
the "honeymoon ' period accorded to new CEO's, but managing the change required heavy 
personal attention: 

Of course, this new thinking was in quite sharp contrast to some of the skills and 
attitudes of the company. We were introducing a change in management 
philosophy in a company which, in many ways was very skillful and effective, but 
in a different product-market environment. We faced all the issues of attitudinal 
change and retraining which any such change implies. We were moving to a much 
more integrated view of the world and had to encourage a major shift in many 
patterns of the existing culture. This meant a very hard, tough program of selling 
the new ideas within the organization as well as an extensive and personal effort to 
get the new messages and thinking to our potential customers.^^ 

As the key processes were identified and their objectives determined, the company began to 
think about how information technology (its own and from other providers) could enable and 
suppon the processes. The Facilitating Director of processes and systems, Paul Chapman, decided 
that a new approach to developing information systems around processes was necessary. His 
organization identified the information engineering product discussed above as the only one 
consistent with a process orientation, and worked with an external consultant in using the system 
tools to refine and confirm the process identification. The output of the process identification 
consisted of 18 "macro" business processes (for example, logistics) and 145 different "micro" 
processes (e.g., fleet management). 

The senior management team reconvened to prioritize the identified processes for system 
development, and identified seven macro processes as of particular importance: customer order life 
cycle, customer satisfaction, installed equipment management, integrated planning, logistics, 
financial management, and personnel management. The personnel management process was 
selected as the first for systems implementation, because it was viewed as relatively easy to attack, 
and because personnel systems were crucial in tracking the development of the new skills required 
by the company. The personnel system has now been successfully completed, using the 
automated code generation capabilities of the Information Engineering Facility product, in 
substantially less time than with normal methods. 

RXUK's financial situation began to improve as it redesigned its business processes. The 
company emerged from a long period of stagnation into a period of 20% revenue growth. Jobs not 


directly involved in contact with customers were reduced from 1 100 to 800. Order delivery time 
was reduced from an average of 33 days to 6 days. Though many other factors in RXUK's 
markets were changing during this time, O'Brien credits the process redesign for much of the 

Other Xerox divisions heard of RXUK's success with process redesign and began efforts 
of their own. Xerox's U.S. product development and marketing divisions have major cross- 
functional teams performing process redesign. Paul Chapman, RXUK's director of processes and 
systems, has been seconded to Xerox corporate headquarters, where he is heading a cross- 
functional team looking at corporate business processes. Commitment to IT-driven process 
redesign by Xerox senior corporate management is also growing. 


We believe that the industrial engineers of the future, regardless of their formal title or the 
organizational unit that employs them, will focus increasingly on the redesign of business 
processes with IT. We have only begun to explore the implications and implementation of this 
concept, and only a few companies have ventured into the area. Many of the companies who have 
employed IT to redesign particular business processes have done so without any conscious 
approaches or philosophies such as those we have ouUined here. In short, the actual experience 
base with IT-enabled process redesign is limited. 

Yet managing by customer-driven processes that cross organizational boundaries is an 
intuitively appealing idea that has worked well in the companies that have experimented with it. 
And few would question that information technology is a powerful tool for reshaping business 
processes. The individuals and companies that can master the skill of redesigning processes 
around IT will be well-equipped to succeed in the new decade and millennium. 



The authors wish to acknowledge the support of Harvard Business School's Division of Research, 
the Center for Information Systems Research at the MIT Sloan School, and McKinsey and 
Company. They also are grateful for the suggestions and ideas provided by Lynda Applegate, 
James Cash, Warren McFarlan, John Rockart, Edgar Schein, and Michael Scon-Morton. 

1 . L. Gulick, "Notes on the Theory of Organization," in L. Gulick and L. Urwick, eds.. Papers 
on the Science of Administration (New York: Institute of Public Administration, 1937), p.9; 
F.B. Gilbreth, Primer of Scientific Management (New York: D. Van Nostrand Company, 

2. S. Sakamoto, "Process Design Concept: A New Approach to IE," Industrial Engineering 
March 1989, p. 31. 

3. "Office Automation: Making It Pay Off," Business Week, 12 October 1987, pp. 134-146. 
For an alternative perspective, see R.E. Kraut, Ed., Technology and the Transformation of 
White-Collar Work (Hillsdale, N.J.: Lawrence Erlbaum Associates, 1987). 

4. G.W. Loveman, "An Assessment of the Productivity Impact of Information Technologies" 
(Cambridge, MA: MIT Sloan School of Management, Management in the 1990's, working 
paper 90s:88-054, July 1988). Loveman studied microeconomic data from manufacturing 
firms to estimate econometrically the productivity impact of IT in the late 1970's and early 
1980's. In finding no significant positive productivity impact from IT, he argues that his 
findings in manufacturing raise serious questions about impacts in nonmanufacturing firms 
as well. Baily et. al. (1988) studied white-collar productivity and IT as one part of a broader 
inquiry into poor productivity growth. They found no evidence of significant productivity 
gain. See M.N. Baily and A. Chakrabarti, Innovation and the Productivity Crisis 
(Washington, D.C.: Brookings Institution, 1988). 

5. Loveman (1988); Baily et. al. (1988). See also S.S. Roach, "America's Productivity 
Dilemma: A Profile of the Information Economy," Special Economic Study, Morgan Stanley 
& Co., April 1987. 

6. J.F. Rockan and J.E. Shon, "IT in the 1990's: Managing Organizational Interdependence," 
Sloan Management Review, Winter 1989, pp. 7-17. 

7. Robert Horton, who became chairman and chief executive of British Petroleum in March, 
1990, argues that his major concern in setting BFs course in the next decade is "managing 
surprise." Honon's belief is that the external business environment is so unpredictable that 
surprise, rather than managed change, is inevitable. See R. Honon, "Future Challenges to 
Management," MFT Management (Winter 1989), pp. 3-6. 

8. T. Malone, "What is Coordinauon Theory?" (Cambridge, MA: MIT Sloan School of 
Management, Center for Information Systems Research, working paper no. 182, February 
1988); K. Crowston and T. Malone, "Information Technology and Work Organization," 
(Cambridge, MA: MIT Sloan School of Management, Center for Information Systems 
Research, working paper no. 165, December 1987). 

9. G.A. Pall, Quality Process Management (Englewood Cliffs, NJ: Prentice-Hall, 1987). Our 
structurally-oriented definition also complements that of Schein, who focuses on human 
processes in organizations — e.g., building and maintaining groups, group problem solving 
and decision making, leading and influencing, and intergroup processes. 


See E.H. Schein, Process Consultation: Its Role in Organization Development, Volume I, 
Second Edition (Reading, MA: Addison-Wesley, 1988). 

10. For example, see H.S. Gitlow and S.S. Gitlow, The Deming Guide to Quality and 
Competitive Position (Englewood Cliffs, NJ: Prentice-Hall, 1987) Chapter 5. 

11. E.J. Kane, "IBM's Total Quality Improvement System," unpublished manuscript, IBM 
Corporation, Purchase, NY; p. 5; also G.A. Pall, 1987. 

12. See, for example, M.F. Morris and G.W. Vining, "The lE's future role in improving 
knowledge worker productivity," Industrial Engineering July 1987, p. 28. 

13. "Reference Note on Work Simplification", (Boston, MA: Harvard Business School, 1961) 
HBS Case Services #9-609-060. 

14. The relationship between business vision and IT has been explored by several researchers 
under the auspices of the MPT Sloan School's five year "Management in the 1990s" research 
program. An overview volume is scheduled for publication by Oxford University F*ress in 
June 1990. 

15. See, for example, G. Stalk, Jr., "Time — The Next Source of Strategic Advantage," 
Harvard Business Review, July-August 1988, pp. 41-51. 

16. W.J. Bruns, Jr., and F.W. McFarlan, "Information Technology Puts Power in Control 
Systems", Harvard Business Review , Sept.-Oct. 1987, pp. 89-94. 

17. S. Zuboff, In the Age of the Smart Machine (New York: Basic Books, 1988). 

18. E.H. Schein, "Innovative Cultures and Organi2:ations" (Cambridge, MA: MIT Sloan School 
of Management, Management in the 1990's, working paper 90s:88-064, November 1988). 

19. Similarly, it would be possible to employ the information engineering approach to redesign 
specific processes that were selected because of their impact, rather than through information 
engineering. Information engineenng and other redesign approaches based on data modeling 
are necessarily limited in scope. More than data is exchanged in many process relationships. 

20. D. Goodhue. J. Quillard, J. Rockart, "Managing the Data Resource: A Contingency 
Perspective" (Cambridge, MA: MIT Sloan School of Management, Center for Information 
Systems Research, working paper no. 150, January 1987). 

2 1 . Dorothy Leonard-Barton introduced the concept of organizational prototyping with regard to 
the implementation of new information technologies. See D. Leonard-Banon, "The Case for 
Integrative Innovation: An Expen System at Digital," Sloan Management Review, Fall 1987, 
pp. 7-19. 

22. R. Johnson and P.R. Lawrence, "Beyond Vertical Integration — The Rise of the Value- 
Adding Partnership," Harvard Business Review, July-August 1988, pp. 94-101. 

23. J.I. Cash and B.R. Konsynski, "IS Redraws Competitive Boundaries," Harvard Business 
Review, March-April 1985, pp. 134 - 142. See also N. Venkatraman, "IT-Induced Business 
Reconfiguration: The New Strategic Management Challenge," paper presented at the annual 
conference of the MIT Center for Information Systems Research, June 1989. 


24. T.J. Main and J.E. Shon, "Managing the Merger: Building Partnership Through IT Planning 
at the New Baxter," Management Information Systems Quarterly, December 1989, pp. 469- 

25. C.R. Hall, M.E. Friesen. and J.E. Shon, "The Turnaround at U.S. Sprint: The Role of 
Improved Paimership Between Business and Information Management," in progress. 

26. R.R. Johansen, Groupware: Computer Support for Business Teams (New York: The Free 
Press, 1988). Also see C.V. Bullen and R.R. Johansen, "Groupware: A Key to Managing 
Business Teams?" (Cambridge, MA: MIT Sloan School of Management, Center for 
Information Systems Research, working paper no. 169, May 1988). 

27. See Harvard Business School case study, "The Center for Machine Intelligence: Computer 
Support for Cooperative Work," Lynda M. Applegate, 1988 (revised 1989). 

28. J.E. Ashton and F.X. Cook, "Time to Reform Job Shop Manufacturing," Harvard Business 
Review, March-April 89, pp. 106-111. 

29. See cases on "Tiger Creek", "Piney Wood", and "Cedar Bluff in S. Zuboff (1988); other 
industries discussed by Zuboff pnmanly involve informational processes. 

30. One might consider managerial processes synonymous with informational processes. 
Certainly the vast majority of managerial processes, such as budgeting, planning, and human 
resource development, involve informational objects. Yet it is important to remember thai 
informational processes can be either operational or managerial, so we believe that this 
separate dimension of process types is warranted. 

31. A case study describes the process and the creation of the expen system. See "Texas 
Instruments Capital Investment Expen System," Harvard Business School, 1988. 

32. Some aspects of this process improvement are described in a Harvard Business School case 
studv, "Xerox Corporation: Executive Suppon Systems," Lynda M. Applegate and Charles 
S. Osborne, 1988 (revised 1989). 

33. R.H.C. Pugh, address to McKinsey & Co. information technology practice leaders, June 
1989, Munich, Germany. 

34. See, for example, A.R. Cohen and D.L. Bradford. "Influence Without Authority: The Use of 
Alliances, Reciprocitv, and Exchange to Accomplish Work," Organizational Dynamics, 
Winter 1989, pp. 4-17. 

35. See G.A. Pall (1987). See also M.A. Cusamuno, The Japanese Automobile Industry 
(Cambridge, MA: Council on East Asian Soidies. Harvard University, 1985). 

36. L.M. Applegate, J.I. Cash, and D.Q. Mills, "Information Technology and Tomorrow's 
Manager," Harvard Business Review, November-December 1988, pp. 128-136. 

37. David O'Brien, quoted in "Rank Xerox U.K., Office Systems Strategy (C): Developing the 
Systems Strategy," case study from Henley - The Management College, September 1988. 
Other Rank Xerox U.K. information comes from personal interviews. 


Thomas H. Davenpon is a partner at Ernst and Young's Center for Information Technology and 
Strategy in Boston, where he directs research and multi-client programs. He has consulted at 
McKinsey and Co. and Index Group, and has taught at Harvard Business School and the 
University of Chicago. He holds a B.A. degree from Trinity University, and holds M.A. and 
Ph.D. degrees from Harvard University. His current interests include the relationship between 
information technology and organization, and the development of IT infrastructures. 

James E. Short is a research associate at the Center for Information Systems Research at the MIT 
Sloan School of Management. Dr. Shon holds the S.B., S.M., and Ph.D. degrees from MIT. 
His research interests include how technology enables organizations to execute differential 
strategies through enhanced integration and flexible, problem-focused teams and task forces. 


S31k u23 

Date Due^ 

AUG 2 8 im\ 

D h f* f" 




3 9080 01918 3521 

i i*!; is i 1 iS ill